\documentclass[letterpaper, 12 pt, conference]{ieeeconf}  % Comment this line out
                                                          % if you need a4paper
%\documentclass[a4paper, 10pt, conference]{ieeeconf}      % Use this line for a4
                                                          % paper

\IEEEoverridecommandlockouts                              % This command is only
                                                          % needed if you want to
                                                          % use the \thanks command
\overrideIEEEmargins
% See the \addtolength command later in the file to balance the column lengths
% on the last page of the document



% The following packages can be found on http:\\www.ctan.org
\usepackage{graphics} % for pdf, bitmapped graphics files
\usepackage{pdfpages}
%\usepackage{epsfig} % for postscript graphics files
%\usepackage{mathptmx} % assumes new font selection scheme installed
%\usepackage{times} % assumes new font selection scheme installed
%\usepackage{amsmath} % assumes amsmath package installed
%\usepackage{amssymb}  % assumes amsmath package installed
\usepackage{listings}
\lstset{
	basicstyle=\small,
	columns=fullflexible
}

\title{\LARGE \bf
Simulation and Optimization of a Collaborative Multi-Robot Heterogeneous Firefighting System
}

%\author{ \parbox{3 in}{\centering Huibert Kwakernaak*
%         \thanks{*Use the $\backslash$thanks command to put information here}\\
%         Faculty of Electrical Engineering, Mathematics and Computer Science\\
%         University of Twente\\
%         7500 AE Enschede, The Netherlands\\
%         {\tt\small h.kwakernaak@autsubmit.com}}
%         \hspace*{ 0.5 in}
%         \parbox{3 in}{ \centering Pradeep Misra**
%         \thanks{**The footnote marks may be inserted manually}\\
%        Department of Electrical Engineering \\
%         Wright State University\\
%         Dayton, OH 45435, USA\\
%         {\tt\small pmisra@cs.wright.edu}}
%}

\author{Dimitrios Bakllas and Aaron Fineman and Tanay Shah% <-this % stops a space
}


\begin{document}

\maketitle
\thispagestyle{empty}
\pagestyle{empty}


\begin{abstract}
This paper will attempt to create a simulation of a multi-agent autonomous mapping system with the purpose of firefighting. The main focus will be on the scalability of the algorithm and optimization of the system for fast response and optimum use of resources. The system will be a heterogeneous swarm including scouting robots and firefighting robots (which are assumed to be scarce resources.) The metrics of the system will be based on time of completion, effectiveness, and distance traveled. The simulations are geared towards finding an optimum number of robots for a medium sized floor plan (approximately 2000-4000 sq.ft.). Implementation of the simulation will be accomplished using the open source Player-Stage robot simulator.

\end{abstract}

\section{INTRODUCTION}
Multi-robot system (MRS) is an active area of research since decades. The purpose of using MRS is to simplify a task by assigning the same task to a multiple number of robots which in turn will simplify and shorten the time to completion [4]. By using a number of different algorithms each robot in the system moves through the search space by following the best experience of its own and its colleagues to obtain an optimal solution. In order to implement this MRS in this project there will be a need for mapping the partially known area, Simultaneous Localization and Mapping (SLAM) is a fundamental algorithm in mobile robotics research. In a SLAM problem a mobile robot explores and senses an unknown region, constructs a map, and localizes itself in the map [8].

The agents will make use of a distributed control algorithm that receives external commands. The overall goal of the project will be to map a building that is on fire. The robots will update the preloaded out of date blueprint of the building with locations of obstructions and local fires. This multi robot system will be heterogeneous with scouting robots and firefighting robots. The main concern is the scalability of the algorithm across one, several, and many sized systems. For modeling purposes there are going to be several assumptions to constrain the problem space. Main assumptions are that the blueprint of the building is known in advance and that it is fairly up to date. In addition, the robots will have limited communication range to simulate wireless communications in a non-ideal environment. A second constraint added is that the simulation is occurring on a single large floor, rather than worrying about simulating stairs and intra-floor communication. The simulation starts by placing all the robots immediately inside the main door and then activating them. An initial objective is to create a four dimensional map of obstructions that are going to be encountered in the search area.

In order to determine the feasibility and the performance this system a number of metrics are proposed. The robots are assumed to have unlimited battery life. For the first metric the distance traversed will be recorded and stored in a database for analysis. From the traveled distance an accurate representation of battery life can be estimated. Second metric will be response time after a fire is located, meaning, if a fire signal is sent out how long will it take for a firefighter to respond. Third metric will be scalability of the entire system, by presenting a table of time to completion vs. the number of robots to complete a search and elimination of a fire in a specific area.

The final goal of this paper is to achieve a model of an autonomous system that has a potential to imitate or replace firefighters who are going into a burning building and put out local fires. More specifically, the expectations from this project are:
\begin{itemize}
	\item To have a final working simulation of the system
	\item To produce results that will prove or disprove the feasibility of the MRS for this application
	\item To have a metric comparing room configurations like size and obstacle layout
\end{itemize}
The paper is organized as follows. Section II presents the project overview. The assumptions of the simulation are described in Section III. Section IV gives a basic overview of the simulation software. Section V discusses the robots. Section VI summarizes the timeline for the project.  Section VII the results are presented and discussed the results of the simulations. Section VIII discusses future work. Finally Section IX concludes the paper.


\section{PROJECT OVERVIEW}
This project will make use of a simulation because of the dangerous conditions, the cost of creating a staging area, and the availability of robots to form a heterogeneous swarm. The simulation software used is Player-Stage, a popular open-source robot simulator.

Use of a simulation allows for easy changes to the building floor plans, in addition to very quick customizations, which cannot be replicated in the real world. In addition, the environment is fully destructible with no consequences, and can be trivially reverted. However, what should be noted is that the simulations abstract out many important aspects of the real world. In simulations, robots will not take heat or fire damage, their destruction is binary. Battery charge and life can only be estimated. This simulation, assumes the battery life to be infinite. The robots are not burdened by their load or terrain. It is also assumed that the measurements taken by the sensors are perfect and without noise except for the Gaussian white noise added to the system.

\begin{figure}
	\begin{center}
		\leavevmode
		\includegraphics{flow_chart}
	\end{center}
	\caption{A flowchart showing robot progression}
	\label{fig:flowchart}
\end{figure}

\subsection{Group Task}
As shown in Figure \ref{fig:flowchart}, the system will initialize at the entrance of the building. Different dispersion techniques like random search and wall following will be employed and tested to optimize the system. The main task for the scouting robots will be to locate fires. At the same time firefighting robots will attempt to position themselves at a convenient location in each room. Once a fire has been located by a scout, the scout will attempt to pass a message to nearby robots about the fire and need of a firefighter. Firefighters will have to prioritize according to the greedy algorithm that is being tested and see to which fire to attend to first. Once the scout receives confirmation from the firefighting robot the scout will return to its original search for more fires. Since the firefighters are considered scarce resource the algorithm will help with the order and the time of completion putting out the fires.

\subsection{Robot Interactions}
All robot interaction is through a simulated wireless connection. Because infinite range communication is not being used, an abstraction layer must be supplied to handle the range limitations. All communications are assumed to be multicast; all robots in range receive anything sent out. Each time a robot wishes to send a message, a list of all robots within range are compiled, and a message is sent directly to each robot sequentially (simulated multi-cast.)

\subsection{Robot Internal Data}
While there is a lot of data potentially available to the robots, they will be making use of only a limited amount. The numerous sensors robots are equipped with by default do not all provide pertinent information while searching for fires. For example IR sensors will be blinded by the surrounding fires and therefore not provide accurate environment representation. All the robots will have inputs from their sensors, LIDAR, magic fire sensor and at the same time locate and send out signals to firefighters. The robots will be working under a bad-case assumption (close to a worst-case assumption.) The robots have the input of basic mapping sensors available to them, including sonar, LIDAR and odometry. While Stage makes X-Y coordinates available to the robots, this info will not be used during simulation because in a real life situation the robots will not/cannot make use of a GPS in an indoor location.

\subsection{Mapping and Storing of a 4-D Map}
As it was introduced earlier the map will be stored in a 4 dimensional fashion. Storing the map in 4-D simply means that the robot will be able to store a Cartesian coordinate position of its position and a RGB color range of the obstructions. The axes that are going to be used are X, Y, certainty, and fire. X and Y will be the coordinates that line up with X and Y on the blueprint. Certainty and fire would range from 00 to FF detailing how certain the agent is of obstructions and how serious the fire is. This allows the agent to integrate other's maps into its own knowledge base with different trust-values, and for its certainty of obstructions to decay over time (it is more likely for collapses to increase over time, not clear out). Storing fire in this manner both allow an agent to mark fire-obstructions and lets it guess how the fire is spreading. This can allow the agent to predict the likely danger of areas and be able to predict areas that may become blocked off. This four dimensional map can be easily encoded into a bitmap storing the additional axes in the RGB values. This will allow for the certainty and fire to be easily visualized.

\begin{figure}
	\begin{center}
		\leavevmode
		\includegraphics{office}
	\end{center}
	\caption{Map that was created for the simulation of our system}
	\label{fig:map}
\end{figure}

\subsection{Environment Map}
The map selected for the simulations of the system is shown above. The physical size of the floor plan is a square room with and area of 22.9 m\textsuperscript{2}. In the software simulation the map was translated to 10 pixels for every meter. For every simulation cycle the robots will always be initiated at the top left corner of the map. The scouting robots will be the ones in the front and the firefighters will stay behind and wait until a fire is discovered. Although a flight of stairs is shown in the bottom side of the blueprint the stairs are not being used in the simulation and the robots assume that the area is closed off.

\section{SIMULATION ASSUMPTIONS}
\subsection{Robots Assumption}
The heterogeneous swarm of robots will be made up of various numbers of mapping robots and a 25\%-38\% of the number of mapping robots will be firefighting robots. There are going to be three (3) simulations that are going to be performed, number of robots are shown below:
\begin{itemize}
	\item First simulation, three (3) mapping robots and one (1) firefighting robot
	\item Second simulation, eight (8) mapping robots and three (3) firefighting robots
	\item Third simulation, twenty (20) mapping robots and five (5) firefighting robots
\end{itemize}
The firefighting robots will be a limited resource, and their numbers scaled accordingly. All of the robots will be heat resistant but not impervious to fire and rubble. The fires in the simulation have a binary boundary; if a robot gets too close to a fire it is assumed that it is “dead”. The robots will be able to move over varied terrain fairly easily, but cannot traverse large piles of rubble. The same binary boundary applies in this case, so if robots get to close to rabble they get stuck. The firefighting robots will be slower, top speed will be less than 0.3 m/s, than the mapping robots due to their carrying of extinguishing agents. The scouts will have a speed between 0.5 m/s and 1.0 m/s, their speed will be adjusted according to the robots’ processing time. It is assumed in this simulation that the firefighting robots have an infinite supply of extinguishing agent. All robots will be assumed to have an infinite supply of battery.

\subsection{Robot Communication}
We will attempt to simulate communication in a non-ideal environment. To accomplish this, the robots will have a limited communication range due to the smoky environment (approximately 50 meters at the time of this draft.) However, our system will not deal with dropped connections, and assume that if a robot is in range, the connection will not be lost except for malfunction or destruction.

\subsection{Sensors}
We assume that even though the environment is rather smoky, and presents poor or occluded vision, our mapping sensors remain fairly accurate, and the only variance is their standard variance. A list of the sensors is described later on in the paper; each sensor is based on true values researched from company product lists for each type of sensor.

\subsection{Environment}
The environment is largely observable, however, it is non-deterministic. The fire is generated and spreads randomly, using RANDOM(3). Also, the rooms have obstacle in them that have to be avoided by the robots.

\section{SIMULATION SOFTWARE}
Player provides a network interface to a variety of robot and sensor hardware and in conjunction with the program stage is a fast and scalable robot simulator. Player supports multiple concurrent client connections to devices with stage is often used as a Player plugin module, providing populations of virtual devices for Player. As users of this software in this project we were able to write robot controllers and sensor algorithms as 'clients' to the Player 'server'.  There is no difference between the real robot devices and the simulated Stage equivalent robots; which makes the simulation very realist or as realistic as it is wanted to be.

\subsection{Player}
Player allows multiple devices to present the same interface. For example in this project the Pioneer 2 was used and the drivers use Player's 'position' interfaces to allow control of the robot's movement. Thus the same control code can drive many different kinds of robots. Player is also designed to support virtually any number of clients. Player makes no assumptions about how you might want to structure your robot control programs, therefore all assumptions could be programed in. Although Player states that they have client libraries in multiple programming languages, including C++, during programing the project’s simulation we found that there were several bugs in the C++ implementation of Player. The most notable involved the instantiation of multiple robots inside one thread. However this bug was only present on certain platforms but we were not able to pinpoint the configuration that caused this to manifest. Ubuntu’s distribution of Player/Stage was broken; Player/Stage was not able to be directly installed from the repositories. Therefore, it was necessary to compile a custom version of Player/Stage.

\subsection{Stage}
Stage was used as a Player plugin module, and provided us with populations of virtual devices for Player. Robot controllers and sensors were written as algorithms for the 'clients' to the Player 'server'. Stage allows rapid prototyping of controllers destined for real robots. Stage also allows experiments with realistic robot devices you don't happen to have. Clients during simulation or actual implementation cannot tell the difference between the real robot devices and their simulated Stage equivalents.
In the figures below there are examples of simulations from Player/Stage. The simulations are being run in a 2D world environment, but also the simulation can be viewed in a 3D isometric view which helps with visualization of the environment and the simulation.

As can be seen in Figure \ref{fig:stage_sample2}, Stage can handle a large number of robots during a simulation. This feature was very helpful in this project since the scalability of the MRS is one of the metrics that was used to evaluate the system. During the simulation of the actual MRS of the project it was discovered that there was a lot of delay in movement and made the simulations take much longer than expected.

Figure \ref{fig:stage_sample}, shows and example a 3D simulation and how the view could be very helpful to visualize how the system is performing.

\begin{figure}
	\begin{center}
		\leavevmode
		\includegraphics[width=0.4\textwidth]{stage_sample}
	\end{center}
	\caption{Example of a 2D simulation in Stage}
	\label{fig:stage_sample}
\end{figure}

\begin{figure}
	\begin{center}
		\leavevmode
		\includegraphics[width=0.4\textwidth]{stage_sample2}
	\end{center}
	\caption{Example of a 2D simulation in Stage}
	\label{fig:stage_sample2}
\end{figure}

\subsection{System Configuration}
This simulation was implemented in a virtual machine on an Apple laptop. Machine specifications:
\begin{itemize}
	\item Core 2 Duo at 2.5 Ghz
	\item 4GB RAM
	\item VMware Fusion 3.1.2
	\begin {itemize}
		\item Allocated 1 Processor
		\item  Allocated 512 MB RAM 
		\item Guest OS Xubuntu 10.10
	\end {itemize}
	\item Player Version 3.1.0-SVN
	\item Stage Version 3.2.2
\end{itemize}

\begin{figure}
	\begin{center}
		\leavevmode
		\includegraphics[width=0.4\textwidth]{2d_fig}
	\end{center}
	\caption{3 robots in the simulator}
	\label{fig:2d_fig}
\end{figure}

\begin{figure}
	\begin{center}
		\leavevmode
		\includegraphics[width=0.4\textwidth]{3d_fig}
	\end{center}
	\caption{3d view of the simulation}
	\label{fig:3d_fig}
\end{figure}

\section{ROBOTS}
The mapping robots are loosely based on the Pioneer platform due to the range sensor coverage available to a circular base. Player provides a default Pioneer II configuration that will be implemented in the simulation.
The two types of robots used will implement two different architectures. The scouting robots will be based on a hybrid-reactive architecture. It is called a hybrid since higher order processes will have to take over in situations where a fire is discovered or a signal has to be sent to firefighter robots. The firefighting robots will make use of a sense-plan-act architecture. This will allow firefighters to be efficient when attending to fires. 

\subsection{Roles and Capabilities}
The system is based on the use of a heterogeneous swarm of scout robots and firefighting robots. The scouting robots will be equipped with standard IR sensors. The senor is assumed to take continuous distance reading and report the distance, the distance range is assumed to be 20cm ( 8”) to 150cm ( 60”). Also, standard sonar sensors will be utilized, the sensors will be able to detect objects from 0cm to 6.45meters ( 254”) and provides sonar range information with 2.5cm ( 1”) resolution. Finally, SICK LIDAR sensors may be employed, with a field of view of 360 and operating range of 0.1m to 20m (assuming that the ). All values used for sensors were based of typical values of actual sensors according to manufacturer’s websites.

\subsection{Noisy Measurements (SLAM)}
SLAM will be used to update the preloaded map within the known environment and at the same time keep track of the current location of each individual agent. The pseudo code is given below:

\begin{lstlisting}
foreach sensor in sensor_types[] {
   foreach sensor in array[] {
      sensor_matrix[m,n] = sensorProxy.scan[n] + normal(0, error);
   }
}
location = filter_noise(sensor_matrix[],time_slice);
\end{lstlisting}

\subsection{First Come First Serve (FCFS)}
With FCFS, fires will be attended to in the order they were reported. The pseudocode is given below:

\begin{lstlisting}
list fire_locations[];

foreach t in time {
   foreach robot in swarm[] {
      if(FOUND_FIRE_FLAG ==  True) {
         fire_locations.add(robot.location, robot.sensor.temp);
      }
   }
   foreach firefighter in swarm[] {
      if(fire_locations.size > 0) {
         goto(fire_locations[1]);
         pop(fire_locations[1]);
      }
   }
}
\end{lstlisting}

\subsection{Greedy Algorithm}
With the greedy algorithm, the room with the most reported fires will be attended to first. The pseudocode is given below:

\begin{lstlisting}
list rooms[];

while(1) {
   foreach robot in swarm[] {
      if(FOUND_FIRE_FLAG == True) {
         rooms[robot.get_room()] += 1;
      }
   }
   foreach firefighter in swarm[ {
      sorted_rooms = rooms.sort();
      if(sorted_rooms[1] > 0) {
         goto(sorted_rooms[1]);
         sorted_rooms[1] = 0;
      }
   }
}
\end{lstlisting}

\subsection{A*}
A* searches for the least-cost path from a given initial node to goal node. Pseudocode explains the algorithm

Pseudocode
\begin{lstlisting}
function A*(start,goal)
	closedset := the empty set    // The set of nodes already evaluated.
 	openset := set containing the initial node    // The set of tentative nodes to be evaluated.
	came_from := the empty map    // The map of navigated nodes.
 
	g_score[start] := 0    // Cost from start along best known path.
	h_score[start] := heuristic_cost_estimate(start, goal)
	f_score[start] := h_score[start]    // Estimated total cost from start to goal through y.
 
while openset is not empty
	x := the node in openset having the
			lowest f_score[ value
	if x = goal
		return reconstruct_path(came_from,
				came_from[goal])
 
	remove x from openset
	add x to closedset
	foreach y in neighbor_nodes(x)
		if y in closedset
			continue
		tentative_g_score := g_score[x]
			 + dist_between(x,y)
 
	if y not in openset
		add y to openset
		tentative_is_better := true
	else if tentative_g_score < g_score[y]
		tentative_is_better := true
	else
		tentative_is_better := false
 
	if tentative_is_better = true
		came_from[y] := x
		g_score[y] := tentative_g_score
		h_score[y] := heuristic_cost_estimate(y, goal)
		f_score[y] := g_score[y] + h_score[y]
 
return failure
  
function reconstruct_path(came_from, current_node)
	if came_from[current_node] is set
		p = reconstruct_path(came_from,
				came_from[current_node])
		return (p + current_node)
	else
		return current_node
\end{lstlisting}

\section{TIMELINE}
The timeline of the project is broken up in eight (8) parts described below. For easy of understanding a Gantt chart is shown in the appendix with the proposed time allocation per task.

\subsection{Literature Review, Midterm Paper, Presentation}
These tasks have been already completed. Literature review took up the most time in order for the project to be introduced and establish the requirements. During the final days of the review the midterm paper was written and submitted on April 3.

\subsection{Code Implementation and Debugging}
The code implementation begun after right after the midterm presentation, although preliminary work on the code begun earlier. The coding and debugging is given a 17 day period to be completed although it is believed that debugging will be until the end of simulations.

\subsection{Test Simulations}
An eight (8) day period is been allocated for the test simulations but five (5) of the days are overlapping with the code implementation and debugging. Testing will be extended until the day that the paper is due if needed although preferably it will be finished earlier to allow enough time for data analysis and statistical analysis of the simulations.

\subsection{Final Paper and Presentation}
The final paper is due on April 25 and it is given six (6) days to be written and finalized. The paper will be started right after the code implementation is finished and in concurrence with the debugging and the test simulations. At the time the test simulations are finished the presentation will be put together in order to have a global and finalized view of the project. Also, there will be two days left after the paper is due, since the due date is on April 27, which will allow for the presentation to be finalized.

\begin{figure}
	\begin{center}
		\leavevmode
		%\includegraphics{gantt_chart}
		\includegraphics[width=0.5\textwidth]{gantt_chart}
	\end{center}
	\caption{Gantt chart}
	\label{fig:gantt}
\end{figure}

\section{RESULTS}
Current position of the project:
\begin{itemize}
	\item Simulations can handle up to 8 robots at a time in the current configuration of the code
	\item Scouts are able to locate fires and report them to the firefighters
	\item Firefighters are able to locate the most efficient path and navigate to the fires and put them out
\end{itemize}
Results:
\begin{itemize}
	\item Scouts need more than 5 minutes to locate the first fire in three (3) scout swarm
	\item It takes ~30 seconds for firefighters to plot the path location to a fire
\end{itemize}

\section{FUTURE WORK}
In the future, the project would like to explore various mapping sensors in hopes of improving detection in worst-case scenarios. Another area to explore further is the use of sonar-like sensors, including WiFi in an effort to locate humans trapped inside buildings, not just fire (Compressive Cooperative Obstacle Mapping in Mobile Networks)

As a final step of the project implementation of a better map joining algorithm, in hopes of allowing this system to act as/alongside first responders.

\section{CONCLUSION}
This paper proposed a study of a firefighting Multi- Robotic System. The study involved the implementation of a heterogeneous MRS for the purpose of safe and efficient detection and extinguishing fires. The algorithms involved in the system are described in the paper by the authors with example pseudocode. One team of robots viz. The Scouts had the task of mapping and locating fire in a burning building. This information was send to the other team The Firefighters in order to extinguish the fires. For the first metric the distance traversed will be recorded and stored in a database for analysis. From the traveled distance an accurate representation of battery life can be estimated. Second metric will be response time after a fire is located, meaning, if a fire signal is sent out how long will it take for a firefighter to respond. Third metric will be scalability of the entire system, by presenting a table of the time vs. the number of robots to complete a search and elimination of a fire in a specific area.
Overall the implementation of the whole system was intriguing and educational. The most important lesson learned was that there is a need of visualizing and designing the architecture of the system before implementing. The project started with the idea of implementation of many subsystems and configurations. The project goals were overambitious which resulted in a delay and incompletion of the project in the allotted time. The resulting simulation is an oversimplified version of the initial goal. Some of the simulation metrics were realized but the simulation still needs a lot of work.

%\addcontentsline{toc}{section}{REFERENCES}
%\nocite{*}
%\bibliographystyle{ieeetr}
%\bibliography{bib}
\section{REFERENCES}
[1] 	S. L. Sabat and L. Ali, “Accelerated exploration particle swarm optimizer-aepso,”

[2]	 Z. Pengchong, L. Alei, L. Liang, C. Ying, G. Haibing, and Y. Xinan, “An exploration algorithm for a swarm of homogeneous robots,”

[3] 	Y. Mostofi and A. Gonzalez-Ruiz, “Compressive cooperative obstacle mapping in mobile networks,” pp. 524 - 530

[4] 	R. Lakaemper, L. J. Latecki, and D. Wolter, “Incremental multi-robot mapping,” pp. 3846 - 3851

[5] 	K. Konolige, D. Fox, B. Limketkai, J. Ko, and B. Stewart, “Map merging for distributed robot navigation,” pp. 212 - 217 vol.1

[6] 	N. Adluru, L. J. Latecki, M. Sobel, and R. Lakaemper, “Merging maps of multiple robots,”

[7] 	S. Carpin, “Merging maps via Hough transform,” pp. 1878 - 1883

[8] 	A. Leon, R. Barea, L. M. Bergasa, E. Lopez, M. Ocana, and D. Scleicher, “Multi-robot slam and map merging,”

[9] 	H. J. Chang, G. Lee, Y.-H. Lu, and Y. C. Hu, “P-slam: Simultaneous localization and mapping with environmental structure prediction,” pp. 281-293

[10] 	A. Atyabi and S. Phon-Amnuaisuk, “Accelerated exploration particle swarm optimizer-aepso,”

[11]	B.-J. Lee, G.-J. Jung, G. Woo, S.-Y. Jung, and J.-K. Jeon, “Pyro implementation of swarm-bots exploring target objects in an area with irregular barriers,”

[12] 	A. Leon, R. Barea, L. M. Bergasa, E. Lopez, M. Ocana, and D. Schleicher, “Slam and map merging,”

[13] S. Huang, Z. Wang, and G. Dissanayake, “Sparse local submap joining filter for building large-scale maps,”

\end{document}

